\section{Conclusions and future work}

We have presented a fast technique for generic dispatch in \cl{}.
Clearly, our tests do not represent any scientifically convincing
argument that our technique is faster than existing
techniques. Rather, the presentation of the technique itself should be
considered the essence of the paper, and the performance simulations
should only be viewed as indications that our technique is worth
pursuing as the basis of the generic dispatch mechanism in SICL.

Having said that, we can still speculate about the impact of our
technique, should the results be confirmed in a more realistic setting. 

With our technique, the amount of work to be done in a simple slot reader
or slot writer is no greater than the work needed for a non-generic
version, such as \texttt{symbol-name} or \texttt{package-nicknames} in
a typical \cl{} implementation.  Our technique therefore makes it
feasible to make such readers and writers generic, and this is exactly
what we do in SICL.  We use the same \clos{} mechanisms (i.e., class
initialization, class finalization, etc.) for built-in classes as
those used for standard classes, even though built-in classes can not
be redefined.  By using the same mechanism, we remove a number of
special cases, and we are able to simplify the overall structure of the
system. 

It is even possible to go one step further.  The amount of work
required in our dispatch mechanism is no greater than the work needed
in a binary addition function that tests for the exact type of its
arguments.  Hence it is entirely feasible to make such a function
generic, allowing the user to add methods for other kinds of objects
such as polynomials or other mathematical objects.  For reasonable
performance, it would still be required to capture special cases such
as fixnum or floating-point addition and inline them, but the default
function could very well be an ordinary generic function without any
significant loss of performance. 

Although it is easy to switch to a different mechanism when the number
of methods turns out to be very large, or more generally, when the
call history contains a large number of elements, preliminary tests
indicate that it might not be necessary to do so.  The canonical
example of a generic function where a different mechanism might be
considered is that of \texttt{print-object}.  However, our preliminary
tests show that the additional cost of a comparison is very small (a
single processor cycle) so that even if the call history is very
large, the cost of these comparisons is modest. 

For a scientifically significant comparison of our technique to
existing techniques, we first need to get \sicl{} into a sufficiently
finished state that more elaborate tests can be designed.  In
particular, we then need to test situations where cache misses might
significantly impact performance.  Furthermore, we need to gather
information about techniques used in existing high-performance
implementations, a task which may not be easy since several of the
existing high-performance implementations are commercial and closed
source.
